ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98c.txt/000029_icon-group-sender _Tue Sep 15 12:29:41 1998.msg

Internet Message Format | 2000-09-20 | 4KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA10444
    for <[e-mail]>; Tue, 15 Sep 1998 12:29:39 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA03607; Tue, 15 Sep 1998 12:29:11 -0700
Message-Id: <[e-mail]>
Date: Tue, 15 Sep 1998 12:17:54 -0500
From: MJE <[e-mail]>
Reply-To: [e-mail]
Organization: None
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: [e-mail]
Subject: Re: Context Switching
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Errors-To: [e-mail]
Content-Transfer-Encoding: 7bit
Status: RO

Thanks, but I think you missed my point.  The hidden assumption here is
that Icon function calls shall behave exactly like C function calls.  I
am trying to say that, with auxiliary data structures, the job might be
done without threads.

The Icon compiler could be made smart enough to know when a function
involves co-expressions, and when it does, not to use "standard" stack
frames that have to be swapped in and out, but some other kind of data
structure (heap allocation) for the local variables.

I understand that if you need to replace processor-level stack frames,
then yes you need assembler code.  I have done that myself in
asynchronous drivers that return from deeply nested routines.

My point is:  maybe there's a better way to handle the context switching
requirement than stack-swapping.  There is no law that says Icon has to
declare local variables internally in the same fashion as C, on the
stack frame.

Mark




[e-mail] wrote:
>
> Yes.. it really does require a seperate "thread" of execution.  The
> coswitch routine (the assembler code used for doing the context switch)
> replaces the C stack frame with a different stack frame then re-invokes
> the interepreter code.  Note that this is not a "whole seperate executable"
> but preserving the current dynamic set of variables while the co-routine
> is running.
>
> Also note that if you dig deep enough into co-processes (co-routines and
> co-expressions) you will find that this is what is really going on under
> the covers.
>
> The algorithm used by Icon expressed in a C-ish pseudeo code is:
>
> coswitch( old_cs, new_cs, first )
> int *old_cs, *new_cs, first;
> {
>     /* save SP, frame pointers, and other registers in old_cs */
>     if ( first == 0 )
>     {
>         /* load sp from new_sp[0] and clear frame pointers */
>         interp( 0, 0 );
>         syserr( "interp() returned in coswitch" );
>     }
>     else
>     {
>         /* load sp, frame pointers and other registers from new_cs */
>     }
> }
> ---------
>
> To implement the coswitch function using threads, one would have
> to locate where coswitch is called, change the allocation of the
> co-expression stack to a creation of a thread that immediately blocks
> on a semaphore defined in the co-expression block.
>
> Coswitch then would be passed the current co-expression's semaphore
> and the co-expression's semaphore to swap to, "post" the called semaphore
> and wait on the calling semaphore (if any of that makes sense).
>
> Taking this alittle further, one might want to have a "master" thread
> (the original thread created by the system) and then when &main is created
> create a new thread for &main.  This would allow &main to be "destroyed"
> and still have the "master" thread always there.  The master thread could
> be used as a syncronizer if for some reason the OS needed stuff created
> by a parent thread.  If done correctly, co-expressions could actually
> be executed in parallel (have the master thread perform all memory
> allocations, GC, file, etc).
>
> Cheyenne